fix: a 400 directLinkedIn.unknown to a LinkedIn send is outcome.unknown - #32

What changed

• On the send call of the four LinkedIn sends (contact linkedin-connect, linkedin-message, linkedin-inmail, linkedin-voice), a 400 with Reply's code directLinkedIn.unknown is now outcome.unknown (exit 3) instead of reply.refused (exit 1). The error keeps status 400 and Reply's code in reply_code, and its hint is the one every lost send carries: running the command again may send it twice. A send Reply names in the answer (reference, state, send_after) stays under details, as on every other refusal of a send.
• The rule beside it is unchanged: a 400 to a send whose JSON carries neither a code nor errors[] is outcome.unknown too.
• Everywhere else directLinkedIn.unknown maps as before: under any status other than 400, on contact send-email, and on the contact import that a send given a person's fields (--contact -) makes first.
• contact send-email is unchanged. An exception escaping an email send is a 500, already outcome.unknown. A 400 contact.emailSendingFailed says the email was not sent and stays reply.refused with Reply's code kept.
• The sends' --help and the README's section on the commands that are not safe to re-run name the new case.

Why

Reply answers an exception escaping a LinkedIn send with a 400 directLinkedIn.unknown and a generic detail, and it uses the same code for a provider answer it cannot map. In either case the send may already have been made. Reported as reply.refused, it told the caller that nothing was sent, and an agent acting on that could send the same message twice. outcome.unknown is the CLI's answer for "the send may or may not have been made", and its hint says to check before repeating.

How it was verified

• npm run build && npm test: before, 924 passed and 5 skipped; after, 928 passed and 5 skipped. The commit was also built and tested in a clean detached worktree.
• The tests were written first and seen failing: two failed before the change (the four LinkedIn sends answered reply.refused, and the named send's details went with it), and the help assertion failed before the help text changed.
• New rows:
  • each LinkedIn send answering a 400 directLinkedIn.unknown is outcome.unknown, exit 3, status 400, reply_code kept, one call, and the hint says a repeat may send it twice;
  • the same answer carrying reference and state keeps them under details;
  • the same code under 409, 403 and 404 maps as before (reply.refused, access.denied, reply.refused) on each LinkedIn send;
  • send-email answering a 400 directLinkedIn.unknown or a 400 contact.emailSendingFailed is reply.refused, exit 1, Reply's code kept, one call;
  • the contact import of a send given a person's fields, answering a 400 directLinkedIn.unknown, is reply.refused and nothing is sent.
• These mutations were run against the change, and a test failed for each one: the status check dropped, the LinkedIn-only scope dropped, the rule dropped, and Reply's code not kept on the error.
• Every test stubs fetch and uses a scratch configuration directory. No call reaches Reply.